Do you turn USB Debugging on the instant you get a new phone?

[Andy Burnelli]

Do you turn USB Debugging on the instant you get a new phone?

If not, why not?

[Carlos E.R.]

On Thu, 1 Dec 2022 22:13:51 +0000, Andy Burnelli wrote:

> Do you turn USB Debugging on the instant you get a new phone?

Certainly not.

>
> If not, why not?

Why would I?

--
Cheers, Carlos.

[sms]

On 12/2/2022 12:13 AM, Carlos E.R. wrote:
> On Thu, 1 Dec 2022 22:13:51 +0000, Andy Burnelli wrote:
>
>> Do you turn USB Debugging on the instant you get a new phone?
>
> Certainly not.
>
>>
>> If not, why not?
>
> Why would I?

There are several very useful apps that must be side-loaded because they
are not permitted on the Google Play Store. While you don't want to
leave USB Debugging Mode on all the time, when you first set up a new
phone it can be useful.

[Carlos E.R.]

Sure, but I don't turn it on till some thing I do the instructions say
to activate it.

So, certainly not the instant I get a new phone.

--
Cheers, Carlos.

[Andy Burnelli]

Carlos E.R. wrote:

>> There are several very useful apps that must be side-loaded because they
>> are not permitted on the Google Play Store. While you don't want to
>> leave USB Debugging Mode on all the time, when you first set up a new
>> phone it can be useful.
>>
>
> Sure, but I don't turn it on till some thing I do the instructions say
> to activate it.
>
> So, certainly not the instant I get a new phone.

Hi Carlos,

It's all about considering catastrophic insurance... ahead of time.

The question was asked to find out who does or doesn't set that critical
switch, and why, so it looks like neither you nor Steve sets it because
neither of you see a reason to set it (which is a perfectly valid reason).

Nobody else answered even as I waited for a while (and even asked Andy
Burns to weigh in on the topic in a different thread). I asked Andy to add
his advice because I know Andy knows what most people do not know.

And what most people do not know, which was the point of asking this
question the way it was asked, is what are they going to do when...

*The USb debugging switch is an _insurance_ policy.*

What are people (not just you) on this newsgroup going to do if/when
they _need_ that insurance and it's no longer available to them?

Then what?

That's the question I am hoping to kindly inform people to ponder.
Before you _need_ that insurance.

Because if you wait until you need it, it's already too late.
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to think about why they _need_ this insurance.

[micky]

In comp.mobile.android, on Thu, 1 Dec 2022 22:13:51 +0000, Andy Burnelli

<sp...@nospam.com> wrote:

>Do you turn USB Debugging on the instant you get a new phone?
>
>If not, why not?

I take a drink of Bacardi the instant I get a new phone.

[sms]

The first thing I do is to load all the apps I want which includes a
couple of non-Google Play Store apps. So it's the first thing I do, but
then of course you want to turn USB debugging off after that.

[JAB]

On Sat, 03 Dec 2022 18:41:49 -0500, micky <NONONO...@fmguy.com> wrote:

> I take a drink of Bacardi the instant I get a new phone.

If you don't enable usb debugging and if later the screen becomes
unresponsive how are you going to work with the phone (or access sd0 data)?

[JAB]

On Sat, 3 Dec 2022 17:08:49 -0800, sms <scharf...@geemail.com> wrote:

> The first thing I do is to load all the apps I want which includes a
> couple of non-Google Play Store apps. So it's the first thing I do, but
> then of course you want to turn USB debugging off after that.

You don't need USB debugging to do any of that although it's handy.
But you do need USB debugging if your screen ever becomes non responsive.

[Carlos E.R.]

So, someone that steals your phone has access to the data inside?

--
Cheers, Carlos.

[Andy Burns]

Carlos E.R. wrote:

> JAB wrote:
>
>> If you don't enable usb debugging and if later the screen becomes
>> unresponsive how are you going to work with the phone (or access sd0 data)?
>
> So, someone that steals your phone has access to the data inside?

Isn't USB debugging "paired" to the fingerprint of a specific computer?
Not sure where the fingerprint comes from on the computer, though.

[micky]

In comp.mobile.android, on Sun, 4 Dec 2022 21:30:10 +0000, Andy Burns

<use...@andyburns.uk> wrote:

>Carlos E.R. wrote:
>
>> JAB wrote:
>>
>>> If you don't enable usb debugging and if later the screen becomes
>>> unresponsive how are you going to work with the phone (or access sd0 data)?

I don't know. I didn't know any of this was a possibility, a problem, or
that there was a usb debugging remedy until I started reading this
thread.

>>
>> So, someone that steals your phone has access to the data inside?

Someone did steal my phone in Greece, but I don't think I had any
information of value in it. Of course he also took my wallet with an
American credit and debit card, but afaict, he didn't use either of
them. He took them around 7PM on a Friday and I had no way to report
them stolen until Saturday, when I reported one of them. But the other
one said the system was down when I called the US on the telephone, and
said the same thing when I found both a PC and an smart phone with a
webbrowers. I couldn't start trying to reach anyone for 14 hours and
didn't reach any one for another 36 hours.

I don't see how they could have rejected a thief's charges without my
knowing about it, or even before they got my report. There was a valid
rentacar charge at the Athens airport, which should have convinced the
computer I was there. Still, if he bought car parts or something a
tourist would not buy, could they have rejected the charge, Yes, but not
bothered to tell me about it? Hard to believe.

IOW, while he might used the phone as a phone, Idon't think he stole
anything from inside or by using the credit/debit cards.

He also stole my passport, but since computers, I would think stolen
passports are nowhere near as valuable, since every point of entry
anywhere in the world knows what passports have been stolen. I went to
report that on Saturday, but the embassy/consulate guard told me to come
back on Monday.


I complained to them later that they should not disable their stolen
card reporting system, which should be a very tiny part of their system,
just so they can update other parts of their data. They didn't reply to
me. It's midwest bank, but not in Chicago. It's some overgrown small
town bank and they act like it. I told them that when I wrote them.

I guess I could test the phonecall by calling, but I can't call every
possible hour it might not be working; And testing computer reporting
is much harder yet, because I'd have to tell them my card was stolen in
order to find out if they would take the information. And then my card
wouldn't work.

>
>Isn't USB debugging "paired" to the fingerprint of a specific computer?
>Not sure where the fingerprint comes from on the computer, though.

I don't use a fingerprint or lock my phone in any way.

[Andy Burnelli]

Hi Andy,

The heartfelt goal is to plan for recovery when/if the screen is smashed.
The question is how people plan to recover when their screen is smashed.

Regarding the keys, I'm not sure how it works but this implies you can
recover keys from ~/.android/adbkeys.pub in the desktop previously used.
*Accessing An Android Device With Broken Screen Via ADB and Unauthorized Machine in 2022*
<https://android.stackexchange.com/questions/247876/accessing-an-android-device-with-broken-screen-via-adb-and-unauthorized-machine>

Note that the methods have _changed_ over time, as of Android 11 & 12:
*access unauthorized android device from adb shell when device screen broken*
<https://stackoverflow.com/questions/47008625/access-unauthorized-android-device-from-adb-shell-when-device-screen-broken>

Overall, I'm trying here with this thread to teach people by forcing them
to think about what they're going to do when their screen no longer works.
*A quick guide to accessing a locked phone with a cracked screen*
<https://forums.androidcentral.com/general-help-how/376515-quick-guide-accessing-locked-phone-cracked-screen.html>

To be sure, I'm trying to _teach_ people something they're resistant to
learn (which can be seen by the fantastical objections they're hurling).
*How to View Broken Phone Screen on Computer?*
<https://www.partitionwizard.com/partitionmagic/view-broken-phone-screen-on-computer.html>

But it's to their advantage (not to mine) to understand the lesson here.

As for the original topic, have you ever mirrored your Android phone onto
your desktop computer so that you operate the Android phone wholly on a PC?
<https://i.postimg.cc/hjkVFyqJ/scrcpy07.jpg> Wi-Fi mirroring on a PC

If so, what's the _first_ switch you need to set in order to mirror it?
<https://i.postimg.cc/TYvqdxCT/vysor35.jpg> USB mirroring onto a PC

Let's answer the question first of how you're going to recover your phone
when the screen is responsive before we go into what slum people live in.
*How to Access an Android Phone with a Broken Screen*
<https://www.linkedin.com/pulse/how-access-android-phone-broken-screen-brian-murutu>

In summary, the goal here is to first get people to think about how they're
going to recover from a broken screen before it happens, and, if we even
get that far (which we may not given the fantastical objections), then we
can write a proactive tutorial that allows us to recover when it happens.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to teach people the value of USB debugging = on.

[Alan]

On 2022-12-04 19:35, Andy Burnelli wrote:
> Andy Burns wrote:
>
>> Carlos E.R. wrote:
>>
>>> JAB wrote:
>>>
>>>> If you don't enable usb debugging and if later the screen becomes
>>>> unresponsive how are you going to work with the phone (or access sd0
>>>> data)?
>>>
>>> So, someone that steals your phone has access to the data inside?
>>
>> Isn't USB debugging "paired" to the fingerprint of a specific computer?
>> Not sure where the fingerprint comes from on the computer, though.
>
> Hi Andy,
>
> The heartfelt goal is to plan for recovery when/if the screen is smashed.
> The question is how people plan to recover when their screen is smashed.

You mean like if you had a backup that ran every night while you slept?

[micky]

In comp.mobile.android, on Sun, 4 Dec 2022 22:15:29 +0100, "Carlos E.R."

I seem to remember USB debugging interfering with something else when I
had it on on some prior phone. Didn't it do that? Does it still?

[Carlos E.R.]

So, are you really saying that, if I turn on USB Debugging a non
authorized computer can access inside my phone, without me authorizing it?

You have then convinced me that I NEVER want to turn that on.

--
Cheers, Carlos.

[Andy Burns]

Andy Burnelli wrote:

> Andy Burns wrote:
>
>> Carlos E.R. wrote:
>>
>>> JAB wrote:
>>>
>>>> If you don't enable usb debugging and if later the screen becomes
>>>> unresponsive how are you going to work with the phone (or access sd0 data)?
>>>
>>> So, someone that steals your phone has access to the data inside?
>>
>> Isn't USB debugging "paired" to the fingerprint of a specific computer?
>> Not sure where the fingerprint comes from on the computer, though.
>

> The heartfelt goal is to plan for recovery when/if the screen is smashed.
> The question is how people plan to recover when their screen is smashed.
>
> Regarding the keys, I'm not sure how it works but this implies you can
> recover keys from ~/.android/adbkeys.pub in the desktop previously used.

So if the thief doesn't have access to the machine the phone was previously
paired with, then you're not open to them using USB debugging to access your date.

If the thief does have access to the previously paired machine then they have
probably cleaned you out of house and home ...

[Andy Burnelli]

Carlos E.R. wrote:

> So, are you really saying that, if I turn on USB Debugging a non
> authorized computer can access inside my phone, without me authorizing it?
>
> You have then convinced me that I NEVER want to turn that on.

Hi Carlos,

I'm not here to deprecate anyone but to teach them (& to learn from them).

If what you're worried about is someone stealing your phone, that's just
not the topic here, especially as it's my understanding they can ALREADY do
what you're worried about... with or without you turning USB debugging on.

But someone stealing your phone is simply not the point of this thread.

The whole point of this thread is to kindly and helpfully make people aware
that if they do NOT set the USB debugging ahead of time (and a few other
things like authenticate with a computer and save that authentication)...

*When their screen breaks, they're dead.*

They cry. They wail. They fret. They fuss. They scream. They pout.

But they are dead for one reason and one reason alone - which is they
didn't think ahead enough to do a few very simple things ahead of time.

1. Turn USB debugging = on
2. Connect once to a trusted PC & save the authentication
3. Turn off the automatic release of those authentication keys
4. Set the default USB mode = file transfer

That's all.
I'm trying to help people NOT be dead when their screen eventually breaks.

Because if they didn't set USB debugging on, then they're dead.

If you don't believe me, look at this thread I compiled during the summer
of _hundreds_ of people who were dead simply because they didn't think
ahead to set the USB debugging switch on BEFORE their screen became
unresponsive.

*What is the best XDA solution to control Android on the PC & recover data*
*over USB or Wi-Fi when the user suddenly has an unresponsive broken screen?*
<https://forum.xda-developers.com/t/what-is-the-best-xda-solution-to-control-android-on-the-pc-recover-data-over-wi-fi-when-the-user-suddenly-has-an-unresponsive-broken-screen.4455331/>

Please read that thread before you respond so that you understand what
you're up against when it comes to your screen becoming unresponsive.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to make the point of why USB debugging is useful.

[Andy Burnelli]

Andy Burns wrote:

> So if the thief doesn't have access to the machine the phone was previously
> paired with, then you're not open to them using USB debugging to access your date.
>
> If the thief does have access to the previously paired machine then they have
> probably cleaned you out of house and home ...

Hi Andy,

Thanks for clarifying that only the one "trusted" computer will be a risk,
and even then, Android, by default, untrusts that one computer after from 1
to 7 days according to what it says in my Android USB debugging settings.

As you are aware, my goal is always to be purposefully helpful so that my
tutorials can be run, step by step, by anyone, as general purpose solutions
but I have to test on something - so I test those solutions on what I have.

To that end, I spent a few hours last night writing & testing this tutorial
on the XDA Developers site in the specific Samsung Galaxy A32-5G forum.

*How to un-freeze an unresponsive Samsung Galaxy A32 5G with reboot,*
*reset, factory reset, odin mode, download mode, android recovery mode*
*& debug mode*
<https://forum.xda-developers.com/t/how-to-un-freeze-an-unresponsive-samsung-galaxy-a32-5g-with-reboot-reset-factory-reset-odin-mode-download-mode-android-recovery-mode-debug-mode.4526629/>

If you get a chance, can you check out that nascent tutorial to let me know
what I'm missing (because I've only run about half the solutions there).

1. First I explain all the ways to get the phone into debug mode, odin
mode, download mode, factory reset mode, android recover mode, etc.

2. Then I run through a firmware recovery process using Odin & Samfw.

3. Then I recover Samsung firmware again, this time using Odin & Frija.

4. Then I cover how to mirror your screen over USB (and later, over Wi-Fi).

5. And then I will be covering how to mount the Android file system
(both sd cards) over Wi-Fi as Windows drive letters using WebDAV.

6. I don't know if this particular phone can be rooted yet, but if it
can be rooted, I'll likely add a section on how to root it after that.

I don't know how your pixels do things, but those are apparently the
canonical Samsung-specific steps to recovery when a phone is unresponsive.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to agree with Andy on the trust authentication.

[Andy Burnelli]

Andy Burnelli wrote:

> Regarding the keys, I'm not sure how it works but this implies you can
> recover keys from ~/.android/adbkeys.pub in the desktop previously used.
> *Accessing An Android Device With Broken Screen Via ADB and Unauthorized Machine in 2022*
> <https://android.stackexchange.com/questions/247876/accessing-an-android-device-with-broken-screen-via-adb-and-unauthorized-machine>

Since I'm all about helping others, even those who don't know enough about
Android to use adb or to even think about the power it provides...

Just as a datapoint, while I use a variety of adb implementations, I looked
for these stored keys and found the files, albeit they were rather old.

Directory of C:\Users\andyburnelli\.android
11/25/2022 03:39 PM <DIR> .
11/25/2022 03:39 PM <DIR> ..
12/14/2020 01:27 PM 1,732 adbkey
12/14/2020 01:27 PM 709 adbkey.pub
11/25/2022 03:39 PM 936 adb_known_hosts.pb
08/06/2022 08:16 AM 185 analytics.settings
12/16/2020 12:37 AM <DIR> avd
12/14/2020 04:57 PM <DIR> breakpad
08/06/2022 09:15 AM <DIR> cache
12/14/2020 01:26 PM 2,107 debug.keystore
12/14/2020 01:29 PM 0 debug.keystore.lock
12/16/2020 12:36 AM 4,640 emu-last-feature-flags.protobuf
12/16/2020 12:36 AM 67 emu-update-last-check.ini
12/16/2020 12:37 AM 119 maps.key
12/16/2020 12:36 AM 171 modem-nv-ram-5554
12/14/2020 12:59 PM <DIR> studio
10 File(s) 10,666 bytes

Note that I do not use the adb inside of Android Studio much, since any adb
works for what I use it for, so this is probably a feature of AS perhaps?

Andy, do you think _old_ keys would work in an emergency situation?

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to check where the adb authentication keys are.

[Carlos E.R.]

On 2022-12-05 17:13, Andy Burnelli wrote:
> Carlos E.R. wrote:
>
>> So, are you really saying that, if I turn on USB Debugging a non
>> authorized computer can access inside my phone, without me authorizing
>> it?
>>
>> You have then convinced me that I NEVER want to turn that on.
>
> Hi Carlos,
>
> I'm not here to deprecate anyone but to teach them (& to learn from them).
>
> If what you're worried about is someone stealing your phone, that's just
> not the topic here, especially as it's my understanding they can ALREADY do
> what you're worried about... with or without you turning USB debugging on.
>
> But someone stealing your phone is simply not the point of this thread.

Yes it is, to me. You do not define what we talk about.

The point is the question: Do you turn USB Debugging on the instant you
get a new phone?

Answer: No.

Q: Why?

A: well, you just told me of a reason: anybody that gets hand of my
phone can snoop inside all I many have.

The rest of what you posted I will not read, way too long.

--
Cheers, Carlos.

[Andy Burnelli]

Carlos E.R. wrote:

> anybody that gets hand of my
> phone can snoop inside all I many have.

Didn't Andy already inform you that they _also_ need your trusted computer.

[Carlos E.R.]

No. Only a hint.

--
Cheers, Carlos.

[Andy Burnelli]

Carlos E.R. wrote:

>>> anybody that gets hand of my phone can snoop inside all I many have.
>>
>> Didn't Andy already inform you that they _also_ need your trusted computer.
>
> No. Only a hint.

Hi Carlos,

It wasn't a hint from Andy. It was a sledgehammer. :)

They need your phone PIN, your computer password, plus your phone & your
computer all of which you would have - but presumably they do not have.

If they have all that, then USB Debugging is already theirs for the taking.

Anyway, the whole point of this kind-hearted thread is to communicate to
people who have the capacity to learn that they need to consider doing a
few simple things _ahead of time_ to be able to interact with the phone
when the screen becomes unresponsive or when the boot OS needs fixing.

1. Turn USB debugging = on (and leave it on)
2. Connect once by USB to a trusted PC & either save the resulting
authentication keys, or, turn off the automatic release of
those authentication keys (I'm not yet sure the best steps)
3. Set the default USB mode = file transfer

This entire thread is a kind-hearted suggestion that, if they do these
things _ahead_ of time, they will be able to interact with their phone.

If they don't do them ahead of time, they won't be able to use the phone.

However, like all threads of a technical topic, unknown issues always come
up, which is a good thing.

In this case, one unknown is how to preserve the authentication keys:
Android: /data/misc/adb/adb_keys
Windows: C:\Users\{you}\.android
Linux: ~\.android

And then, once you've preserved them, how to reactivate them when needed.

*Andy - do you have any idea if a simple _copy_ will suffice?*

[Alan]

On 2022-12-05 08:13, Andy Burnelli wrote:
> Carlos E.R. wrote:
>
>> So, are you really saying that, if I turn on USB Debugging a non
>> authorized computer can access inside my phone, without me authorizing
>> it?
>>
>> You have then convinced me that I NEVER want to turn that on.
>
> Hi Carlos,
>
> I'm not here to deprecate anyone but to teach them (& to learn from them).

Well that's an out and out lie and a second lie in the parenthetical!

:-)

>
> If what you're worried about is someone stealing your phone, that's just
> not the topic here, especially as it's my understanding they can ALREADY do
> what you're worried about... with or without you turning USB debugging on.

The can steal your phone, sure.

But access your data?

If USB debugging makes that possible, then having it on is plainly stupid.

>
> But someone stealing your phone is simply not the point of this thread.
>
> The whole point of this thread is to kindly and helpfully make people aware
> that if they do NOT set the USB debugging ahead of time (and a few other
> things like authenticate with a computer and save that authentication)...
>
>   *When their screen breaks, they're dead.*

Unless they have a backup...

...as actually intelligent people do.

(BTW, as I type this my phone's last backup was at 0441 today.)

>
> They cry. They wail. They fret. They fuss. They scream. They pout.
> But they are dead for one reason and one reason alone - which is they
> didn't think ahead enough to do a few very simple things ahead of time.
>
> 1. Turn USB debugging = on
> 2. Connect once to a trusted PC & save the authentication
> 3. Turn off the automatic release of those authentication keys
> 4. Set the default USB mode = file transfer
>
> That's all.
> I'm trying to help people NOT be dead when their screen eventually breaks.

So get them a system that just backs up their phones.

>
> Because if they didn't set USB debugging on, then they're dead.

Unless you do regular backups...

...as actually intelligent people do.

>
> If you don't believe me, look at this thread I compiled during the summer
> of _hundreds_ of people who were dead simply because they didn't think
> ahead to set the USB debugging switch on BEFORE their screen became
> unresponsive.

Because they didn't do regular backups...

...as actually intelligent people do.

[Andy Burnelli]

micky wrote:

>>So, someone that steals your phone has access to the data inside?
>
> I seem to remember USB debugging interfering with something else when I
> had it on on some prior phone. Didn't it do that? Does it still?

I'm all about good heartedly always adding on-topic technical value to the
group tribal knowledge, so I spent a lot of effort here to help others.
<https://i.postimg.cc/jdXm2ggJ/sndcpy02.jpg> adb + *sndcpy* example
<https://i.postimg.cc/xjz3V8Gs/vysor32.jpg> adb + *vysor* example
<https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> adb + *scrcpy* example

AFAIK, there are no known "problems" that anyone has brought up here which
are associated with turning USB debugging on (at least that I know of).

The issue Carlos brought up requires the thief have so many things that
it's almost impossible for the scenario he fears to ever actually occur.

Certainly though, you can turn on specific options within "Developer
options" that can "interfere" with tools, but as far as anyone has shown in
this thread, turning on "USB debugging" within "Developer options" just
allows USB debugging (which is what the Android Debug Bridge needs).
<https://i.postimg.cc/QtbR1GY0/webdav13.jpg> Android Debug Bridge (adb)

Certainly billions of Android users are using adb every day, so if it was
so dangerous to use, you'd think the net would be filled with horror
stories.

BTW, to help document what options I recommend people set, I turned off my
Developer options a few times and turned it back on to see what changed.

Obviously each Android version has more & more options, but for my Android
12, here's what I found happened when I turned Developer options off & on.

Listed in order of appearance in my Samsung Android 12 menus...

Turn Developer options = off (the menu after "About phone" disappears).
A. Quick settings developer tiles, Wireless debugging goes off
B. USB Debugging goes off (if it was on)
C. Wireless debugging goes off (if it was on)
D. Disable adb authorization timeout goes off (if it was on)
E. Enhanced Wi-Fi MAC randomization goes off (if it was on)
F. Mobile data always active goes off (if it was on)
G. Default USB configuration remains set to what you previously set
H. Select mock location app goes off (if it was on)

Here's what I recommend others set for privacy & functionality:
(again, listed in the order they appear in the developer options)
a. Quick settings developer tiles, Wireless debugging (turn on)
[Interestingly its position in the Android tile remains valid!]
<https://i.postimg.cc/JhjpnRgh/webdav14.jpg> Tile position returns!
b. USB Debugging (turn on to allow adb connections over USB or Wi-Fi)
c. Wireless debugging (turn on to allow adb connections over Wi-Fi)
d. Disable adb authorization timeout (turn on but it won't matter much)
e. Enhanced Wi-Fi MAC randomization (turn on for privacy per AP)
[Note you've also set MAC Address type = Randomized MAC in settings]
f. Mobile data always active (turn on for faster Wi-Fi:data switching)
g. Default USB configuration (mine is set to "Transferring files")
h. Select mock location app (turn on & set to your fake GPS app)

If you use adb every day, like I do to mirror Android (keyboard, mouse,
monitor & clipboard & sound) onto the desktop. what other "Developer
options" switches do you habitually set in addition to "USB Debugging"?
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Mirror Android on the PC

Now I can connect Android over Wi-Fi (I rarely use USB today) to operate a
phone from a Windows PC sharing the monitor, mouse, keyboard & clipboard.
<https://i.postimg.cc/jdXm2ggJ/sndcpy02.jpg> adb + *sndcpy* example
<https://i.postimg.cc/xjz3V8Gs/vysor32.jpg> adb + *vysor* example
<https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> adb + *scrcpy* example

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to help others understand how to use adb with a PC.

[Andy Burnelli]

Andy Burnelli wrote:

> e. Enhanced Wi-Fi MAC randomization (turn on for privacy per AP)
> [Note you've also set MAC Address type = Randomized MAC in settings]

Clarification of MAC randomization switches & broadcast _nomap SSID issues.
Below are the gory details that you only need if you desire basic privacy.

Here's what I recommend others set for privacy & functionality:
(again, listed in the order they appear in the developer options)
a. Quick settings developer tiles, Wireless debugging (turn on)
[Interestingly its position in the Android tile remains valid!]
<https://i.postimg.cc/JhjpnRgh/webdav14.jpg> Tile position returns!
b. USB Debugging (turn on to allow adb connections over USB or Wi-Fi)
c. Wireless debugging (turn on to allow adb connections over Wi-Fi)
d. Disable adb authorization timeout (turn on but it won't matter much)
e. Enhanced Wi-Fi MAC randomization (turn on for privacy per AP)
[Note you've also set MAC Address type = Randomized MAC in settings]
f. Mobile data always active (turn on for faster Wi-Fi:data switching)
g. Default USB configuration (mine is set to "Transferring files")

[Most phones have the default set to "No data transfer" instead.]

h. Select mock location app (turn on & set to your fake GPS app)

As of Android 10+ there's also a new "Wi-Fi scan throttling" option, which
is on by default so that it reproduces Android 9 Wi-Fi scan throttling of
i. Each foreground app can scan four times in a 2-minute period.
(note that this default allows for a burst of scans in a short time)
ii. All background apps combined can scan one time in a 30-minute period.
<https://betterprogramming.pub/how-to-avoid-wifi-throttling-on-android-devices-494a0cc29dd8>
<https://github.com/VREMSoftwareDevelopment/WiFiAnalyzer/wiki/Android-WiFi-scanning-throttling>

As always, if you know more than I do about this, please add technical
value, clarify existing value, and correct any mistakes I may have made.

Bear in mind everything works together... just as we do on this newsgroup!

The first thing we need to do is clarify what these _two_ switches above do
in the later Android versions to allow for MAC randomization not only per
AP but also per connection. And I should probably touch on what "static ip"
means too.

Note these switches are in my Android 12 but the first one came in Android
10 (as I recall) while the other was added around Android 11 (as I recall).

Note that the very useful "Wireless debugging" tile came only in Android
12, my point being not all these options will be on any older phone.

CAVEAT: For convenience when using adb to connect a Windows (or macOS or
Linux) desktop to Android, you often set the IP address to "static", which
you can no longer do as easily today from a home router as you used to be
able to do whenever you use random MAC addresses! (Ask me how I know this.)

Most people have their home router set to serve addresses out of a block.
[x] Use Router as DHCP Server
[_] Set Address Reservation per device (see below why this is set to off)
[_] Broadcast SSID (this should always be off for privacy reasons)

Note you can no longer "easily" use "Address Reservation" on a typical
home router because it usually requires locking to a specific MAC address.

What you do nowadays, instead, is set a "static" IP address on Android:
Android12: Settings > Connections > {longpress on} Wi-Fi >
{Press on the gear icon for _each_ access point in your settings}
Auto reconnect = off (this should _always_ be "off" for privacy reasons)
View more > IP settings = static
IP address = 192.168.1.4 (set to whatever address you want)
MAC address type = Randomized MAC

Note this last setting randomizes the MAC address *per connection*.
That is, every time you connect to that SSID, it will have the same
(randomized) MAC address. If this is all you set, then you _can_ use
Address Reservation in your router; but there's _another_ MAC randomizer!

As per this thread, there is another MAC randomizer for _each_ connection!
*Do you turn USB Debugging on the instant you get a new phone?*
<https://groups.google.com/g/comp.mobile.android/c/c8b0FRvALmo>

When you turn "Developer options" and "USB debugging" as of Android 11+,
you also get the option to set the MAC randomization for _each_ connection!
Android Settings > Developer options > Enhanced Wi-Fi MAC randomization
"Change this phone's MAC address each time it connects to a network
that has MAC randomization turned on."

Note you need _both_ MAC-randomization settings in order to accomplish this
(and it's suggested you also end your SSID with "_nomap" to complete the
privacy steps - which of course, requires you to not broadcast the SSID).

My point in bringing this up to Android, Windows, and wireless newsgroups
is to communicate these wonderfully new privacy-based options which never
existed before, and which therefore require understanding of what they do.

Note: I'm fully aware that hiding the SSID broadcast is not for _security_
reasons, but many people do not realize hiding it is for _privacy_ reasons!

Specifically, most Android phones driving by your home will upload your GPS
location and your unique router BSSID even if you have "_nomap" appended to
the SSID (unique because you want your unique-as-possible SSID to stay out
of voluminous Internet butterfly/hash tables but that's a separate thing).

Even if Google/Mozilla respect the _nomap on the server side... notice that
distinction because it's the whole point that it's _already_ uploaded even
if you have "_nomap" appended (where we can forget nowadays about
_optout_)... there's no guarantee that the others (e.g., Kismet, Wiggle,
etc.) will respect the _nomap optout request).

The solution is to prevent "most" Android phones from even seeing your
SSID, which can only be done by hiding the broadcast - where - if someone
knows what they're doing, of course _they_ will see your (hidden) SSID -
but "most" phones will not _upload_ a hidden ID to the Internet servers,
and that's why you hide it.

Of course, once you hide it, then you have to worry about your phone
constantly trying to _reconnect_ to it (which shouts out your supposedly
unique SSID everywhere you go), so you also need to turn off the
auto-reconnection option in Android - which is very easily done.

Here are some representative screenshots illustrating some of the above:

<https://i.postimg.cc/jdXm2ggJ/sndcpy02.jpg> adb + *sndcpy* example

<https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> adb + *scrcpy* example
<https://i.postimg.cc/xjz3V8Gs/vysor32.jpg> adb + *vysor* example

<https://i.postimg.cc/QtbR1GY0/webdav13.jpg> Android Debug Bridge (adb)

<https://i.postimg.cc/JhjpnRgh/webdav14.jpg> Tile position returns!

<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Mirror Android on the PC

There is a short description of every option listed above (and others) here
*Explaining every setting in Developer Options* (as of April 2022)
<https://www.xda-developers.com/android-developer-options/>

In summary, it all works together, and each release of software allows more
privacy options - where this clarifying post is to put some of it together
so that you can understand why each specific switch is set and how it has
ramifications for setting other things on your PC, router, and phone.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to clarify Android MAC randomization switches.

[Andy Burnelli]

sms wrote:

> There are several very useful apps that must be side-loaded because they
> are not permitted on the Google Play Store. While you don't want to
> leave USB Debugging Mode on all the time, when you first set up a new
> phone it can be useful.

To keep this thread adding valuable on-topic technical merit...

One point to make in terms of sideloading apps via ADB that is useful
is you can _still_ verify those apps via Google Play if you want to.

First off, Google Play Protect still runs every day unless you explicitly
turned off the daily Google Play Protect scanning which also scans upon
installation of APKs no matter _how_ you sideloaded those app APKs...

Secondly, there's a special Developer option switch that will verify
apps the instant you sideload them over USB via the adb tools
<https://www.xda-developers.com/android-developer-options/>
"Verify apps over USB: This checks applications sideloaded through ADB
for harmful code, similar to how applications downloaded on your device
are verified using Google Play Protect. This might be handy if you're
downloading applications from the web on your computer and installing
them using ADB."

There is also an option, on by default, to verify the byte code of the APK:
"Verify bytecode of debuggable apps:
This is another security measure, and it's enabled by default."

As an aside, and specifically for Steve who knows a lot about refresh
rates, there's also the following option which is useful but unrelated:
"Show refresh rate: This adds a Fraps-like counter at the top of the
screen for checking the current refresh rate, which is helpful for
devices that dynamically switch between refresh rates.
Keep in mind this is not a frame rate counter."
<https://static1.xdaimages.com/wordpress/wp-content/uploads/2022/04/Screenshot_1649901333-1024x379.jpg>

[AJL]

On 12/11/2022 8:20 AM, Andy Burnelli wrote:

> Google Play Protect still runs every day unless you explicitly turned
> off the daily Google Play Protect scanning which also scans upon
> installation of APKs no matter _how_ you sideloaded those app
> APKs...

Play Protect APPEARS to work even if the sideloaded apps (4) are the
Google Play Store series itself. I put them on my Amazon tablets awhile
back and it daily checks and so far has always reported "No harmful
apps found". And does it even though Google also reports those same
tablets as "Device is not certified"...

[Andy Burnelli]

This is important and very useful information about Google Play Protect
because most people think it's somehow (magically?) intimately associated
with the Google Play Store app, or with logging into the Google Play Store.
*It's not.*

They're independent entities that just happen to share a settings activity.
a. Google Play Store
b. Google Play Protect
*They're different things*

I think you're confirming what I had surmised from my experience, right?

A. Google Play Protect "appears" to work when you sideload apps via adb.

B. Overall, it's my understanding Google Play Protect runs automatically
upon every APK install no matter how you install the app.

C. Even so, Google Play Protect runs once, by default, every day, anyway.

Notice you don't even need to log into Google Play Store for this to
happen, and, better yet, you don't even need the Google Play Store enabled
as far as I know.

It's not surprising that Google put the Google Play Protect switches inside
the Google Play Store app, but as far as I can tell, they're completely
independent of each other.

I know this because I never log into the Google Play Store (I don't even
have a Google Account set up on my phone) and yet I can still have Google
Play Protect scan all my APKs upon installation and/or once a day, if I
want it to.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to clarify when Google Play Protect scans APKs.

[Bodger]

Me, I first remove the phone from the box, install it in the prepared
protective case, charge it, connect it to my provider. Then I might have a
bit of ethanol in some form and ruminate over how much I spent on the phone...

[AJL]

On 12/11/2022 2:49 PM, Andy Burnelli wrote:

> They're independent entities that just happen to share a settings
> activity. a. Google Play Store b. Google Play Protect *They're
> different things*

When I installed Google on my Amazon Fire tablets (the latest being an
HD10+ bought last July) I sideloaded 4 files:

1. account manager.apk
2. services framework.apk
3. play services.apk
4. play store.apk

My apk source said the files were required to be installed in that
order. That's what I did. After installation Google automatically
brought the system up to date and once signed in my Amazon tablet
functioned like any other Googled tablet (and with no changes to the
Amazon stuff).

I was kinda surprised that Amazon would allow Google into their tablet.
But for that price range the tablet is IMO one of the better ones so I
was glad to have the extra versatility that Google brings. Sometimes the
Amazon Appstore and the Google Play Store want to update each others
apps but that was easily solved by turning off auto update in both
stores and doing it manually. Otherwise I found no other conflicts.

> I think you're confirming what I had surmised from my experience,
> right?

> A. Google Play Protect "appears" to work when you sideload apps via
> adb.

> B. Overall, it's my understanding Google Play Protect runs
> automatically upon every APK install no matter how you install the
> app.

> C. Even so, Google Play Protect runs once, by default, every day,
> anyway.

> Notice you don't even need to log into Google Play Store for this to
> happen, and, better yet, you don't even need the Google Play Store
> enabled as far as I know.

I don't doubt what you say, I've just never tried it. As you know I've
been long assimilated so was happy to have all Google's advantages on my
otherwise somewhat limited Amazon tablets.

On my tablets, Play Protect reports through the Play Store (upper right
icon > Play Protect). How does it report when there's no Play Store
installed?

[Andy Burnelli]

AJL wrote:

> After installation Google automatically
> brought the system up to date

Oh my. Where do I start. Warning: The response below is complicated simply
because almost everything people _think_ about the Google Play Store...
*is wrong*

You asked good questions but we need to be on a firm basis of understanding
_before_ we can even begin to answer the questions about scans & updates!

Again I probably need to point out that most people haven't studied what the
Google Play Store actually does, and most people therefore simply _assume_
what the Google Play Store does - without ever testing it out.

I'm different than most people because I see details they simply guess at.

I do not use the Google Play Store (since I have no Google Account set up
on my phone - and yet - two things people _think_ are part of the Google Play
Store can be turned on (by default) or turned off (which I do).

These two things most people (seem to) _think_ are part of the Google Play store.
But they're not. They're INDEPENDENT of the Google Play Store.

1. Google Play Protect scanning (daily & upon each APK installation)
2. Updates when APK updates are available in the Google Play Store repo.

Nobody seems to understand that the first item above happens independently
of the Google Play Store itself; and even fewer people realize that the app
updates not only happen independently of the Google Play Store itself, but
even more shockingly, extremely few apps are actually updated.

We covered which apps are updated, in detail, in another thread long ago,
so suffice to say if you want _all_ your apps updated, the Google Play
Store app is NOT the app for the job - because it just doesn't do much.

What you need, if you want all your apps updated, is a specific app that is
_designed_ to update apps that have updates in the Google Play Store repo.

Notice what I'm saying is that two things people "think" are done by the
Google Play Store are not actually done by the Google Play Store (even as
the settings for those two things are in the Google Play Store app).

Here are some illustrative shots from a previous thread on this very topic:
<https://i.postimg.cc/HsXKj7WK/updateallapps01.jpg> Updating all apps doesn't
<https://i.postimg.cc/4djB69pr/updateallapps02.jpg> It's independent of GPS
<https://i.postimg.cc/02xKj04h/updateallapps03.jpg> Only updates SOME apps!
<https://i.postimg.cc/3xxyCJYB/updateallapps04.jpg> Only updates GOOGLE apps!
<https://i.postimg.cc/kgBB3mq0/updateallapps05.jpg> Real update apps are better
<https://i.postimg.cc/fy8TpHFW/updateallapps06.jpg> Some better than others
<https://i.postimg.cc/pLwVw50j/updateallapps07.jpg> No need for a sign in
<https://i.postimg.cc/BZMzpG4C/updateallapps08.jpg> Works even when disabled
<https://i.postimg.cc/g0jQBKrs/updateallapps09.jpg> GP Services is not GP Store
<https://i.postimg.cc/qqVFqVwD/updateallapps10.jpg> They update different stuff
<https://i.postimg.cc/4ymqRF7n/updateallapps11.jpg> Like the GP System version

> I was kinda surprised that Amazon would allow Google into their tablet.

This is good to note since many of us to not have the Amazon tablet.

> But for that price range the tablet is IMO one of the better ones so I
> was glad to have the extra versatility that Google brings.

We have many threads which prove otherwise, but you're welcome to log
into Google Accounts if you think it brings you something of value.

> Sometimes the
> Amazon Appstore and the Google Play Store want to update each others
> apps but that was easily solved by turning off auto update in both
> stores and doing it manually. Otherwise I found no other conflicts.

See above.

The Google Play Store does NOT update apps.
Even what people "think" is the Google Play Store doing the updates,
doesn't update _all_ your apps (even if new versions are in the Google
Play Store repo).

What people "think" is the Google Play Store updating "all" their
apps is simply an Activity inside the Google Play Store app which
updates an extremely limited set of apps on your device.

In my humblest of opinions, people just don't think because most
people _assume_ these two things, both of which are dead wrong.
A. They think the Google Play Store is doing the updates (it's not).
B. They think it updates _all_ their apps (it doesn't).

It's basically worthless, in my humble opinion, but most people
haven't tested it. I have (see the screenshots above for proof).

>> Notice you don't even need to log into Google Play Store for this to
>> happen, and, better yet, you don't even need the Google Play Store
>> enabled as far as I know.
>
> I don't doubt what you say, I've just never tried it. As you know I've
> been long assimilated so was happy to have all Google's advantages on my
> otherwise somewhat limited Amazon tablets.

I don't have a problem with people who do what MARKETING tells them,
but I do have a huge problem when people _assume_ things which are wrong.

In this case, almost everything people assume about the Google Play Store
is dead wrong. In a way, it's like quantum physics where everything you
think you know, is wrong and, if you think you know it, you don't. :)

> On my tablets, Play Protect reports through the Play Store (upper right
> icon > Play Protect). How does it report when there's no Play Store
> installed?

My phone isn't rooted (it can't be rooted, unfortunately); so the Google
Play Store app is "installed" but it's disabled as shown in previous shots.

Sometimes when I test the Google Play Store, I re-enable it; but it does
everything you "think" it does without ever needing to log into it ever.

In summary, what people think is part of the Google Play Store functionality
isn't at all and what people think the Google Play Store updates, it doesn't.

Sigh. It's complicated.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to clarify what the Google Play Store really does.

[Andy Burnelli]

Andy Burnelli wrote:

> In my humblest of opinions, people just don't think because most
> people _assume_ these two things, both of which are dead wrong.
> A. They think the Google Play Store is doing the updates (it's not).
> B. They think it updates _all_ their apps (it doesn't).
>
> It's basically worthless, in my humble opinion, but most people
> haven't tested it. I have (see the screenshots above for proof).

Actually, to be more comprehensive, there are _three_ things most
people _assume_ are done by the Google Play Store, but they're not.

1. They think the Google Play Store is doing app updates (it's not).
2. They think it updates _all_ their apps (it doesn't even come close).
3. They think the Google Play Store is doing the scans (it's not).

In summary, in reality, the Google Play Store is almost completely
superfluous, in that it provides absolutely _nothing_ you don't
already have without it (and there's no need for a Google Account too!).

Sigh.

The problem with most people is they assume things w/o testing them.

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to clarify complexities of the Google Play Store.

[Andy Burnelli]

> AFAIK, there are no known "problems" that anyone has brought up here which
> are associated with turning USB debugging on (at least that I know of).

I'm never afraid to find a contrary opinion such as that brought up by
micky.

Googling furiously to find known problems, this is all I found so far.
*Android Developer Options Explained*
<https://www.xda-developers.com/android-developer-options/>
"some applications & games refuse to launch if USB debugging is enabled."

If you know of a disadvantage of USB debugging that outweighs the
advantages, let us all know as we should never be afraid of facts.
--
Only a fool is afraid of facts (which is why the iKooks are fools).

[micky]

In comp.mobile.android, on Fri, 9 Dec 2022 15:39:03 +0000, Andy Burnelli

<sp...@nospam.com> wrote:

>
>BTW, to help document what options I recommend people set, I turned off my
>Developer options a few times and turned it back on to see what changed.
>
>Obviously each Android version has more & more options, but for my Android
>12, here's what I found happened when I turned Developer options off & on.
>
>Listed in order of appearance in my Samsung Android 12 menus...
>
>Turn Developer options = off (the menu after "About phone" disappears).
> A. Quick settings developer tiles, Wireless debugging goes off
> B. USB Debugging goes off (if it was on)
> C. Wireless debugging goes off (if it was on)
> D. Disable adb authorization timeout goes off (if it was on)
> E. Enhanced Wi-Fi MAC randomization goes off (if it was on)
> F. Mobile data always active goes off (if it was on)
> G. Default USB configuration remains set to what you previously set
> H. Select mock location app goes off (if it was on)

When I plug in a cable from the PC, I get a popup at the bottom that
s ays

Use USB for
No data tranfer, X
File Transfer/Android Auto
Transfer photos (PTP)

Does this mean my Developer Options are On.

[Andy Burnelli]

micky wrote:

> When I plug in a cable from the PC, I get a popup at the bottom that
> says
> Use USB for
> No data tranfer, X
> File Transfer/Android Auto
> Transfer photos (PTP)
>
> Does this mean my Developer Options are On.

By default from what I've read, most Androids are set to "No data transfer"

Probably the best way to tell if Developer options is on is to go to your
Android "Settings" & look to see if you have a "Developer options" menu
(which is often, but not always, the last Settings entry in the list).

As shown below, if Developer options is turned on, the menu will show up.
<https://i.postimg.cc/28324Hdp/devopt01.jpg> Settings > Developer options

Some phones (e.g., Android 10 Motorola G7) put the Developer options menu
in a slightly different location, so it's not always the last in the list.
<https://i.postimg.cc/3N8zZ1vt/devopt05.jpg> Turning Developer Options on

One way to tell that probably works on all Android phones is to press the
"Build number" and if you see what I show below, "You're a developer". :)
<https://i.postimg.cc/jSB0rypj/devopt06.jpg> Press Build number 7 times

Bear in mind the difference in privacy & functionality with developer
options turned on is astoundingly huge compared to it being turned off.
<https://i.postimg.cc/PrqFSfjR/devopt02.jpg> Useful devoptions switches
<https://i.postimg.cc/7LzRSBkP/devopt03.jpg> More devoptions switches
<https://i.postimg.cc/DZFxLn65/devopt04.jpg> Even more devoptions switches

--
Posted out of the goodness of my heart to disseminate useful information

which, in this case, is to help others better understand Developer options.

[micky]

In comp.mobile.android, on Tue, 20 Dec 2022 18:22:27 +0000, Andy

Burnelli <sp...@nospam.com> wrote:

>micky wrote:
>
>> When I plug in a cable from the PC, I get a popup at the bottom that
>> says
>> Use USB for
>> No data tranfer, X
>> File Transfer/Android Auto
>> Transfer photos (PTP)
>>
>> Does this mean my Developer Options are On.
>
>By default from what I've read, most Androids are set to "No data transfer"
>
>Probably the best way to tell if Developer options is on is to go to your
>Android "Settings" & look to see if you have a "Developer options" menu
>(which is often, but not always, the last Settings entry in the list).

There isn't. But I looked at all the jpg's below -- thx -- and then
googled
Developer Options Xiaomi.

It's not the same as a previous phone, even a previous Xiaomi iirc, but
it is on now. And I set to Yes, Screen won't go to sleep while
charging. I really wanted that one.

Skip Screen lock** is already on. I thought I turned it on, when I
first got the phone. Oh, well, my memory could be better. **I
really like this. The previous phone, the cheap Samsung, didn't have
it.